Перейти к основному содержимому

8.06. ИИ агенты

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ
Всем

AI-агенты​

Зачем нужны агенты, если есть языковые модели?​

Искусственный интеллект за последние годы прошёл путь от статических моделей, решающих узкие задачи, к динамическим системам, способным действовать в реальном мире. Первая волна генеративного ИИ была связана с так называемыми пассивными моделями: они отвечали на вопросы, переводили тексты, генерировали изображения — но делали это только по явному запросу пользователя, без инициативы и без способности изменять окружающую среду. Это был прогнозирующий ИИ: мощный, но всё же ограниченный рамками одного запроса и одного ответа.

Следующий качественный скачок произошёл, когда исследователи и инженеры начали рассматривать языковую модель не как самостоятельный инструмент, а как ядерный компонент более сложной системы — агента. Агент — это не просто «больше параметров в модели», это принципиально иной способ организации программного обеспечения. Если классическая разработка подразумевает, что разработчик точно описывает, как достигается цель (алгоритм), то разработка агента подразумевает, что разработчик описывает, что должно быть достигнуто и в каких рамках — а сама система строит план и исполняет его, шаг за шагом, корректируя траекторию по ходу выполнения.

Можно провести аналогию с профессиями: традиционный программист — это каменщик, вручную подбирающий каждый кирпич и кладущий его по чертежу. Разработчик агента — это архитектор и режиссёр: он проектирует пространство действия (контекст), определяет роли исполнителей (инструменты, API), задаёт правила поведения (политики) и направляет автономного «актёра» (языковую модель), чтобы тот достиг цели в рамках сценария.

Сегодня ИИ‑агенты уже внедрены в сердце новых версий повседневных программ: Microsoft Copilot интегрирован в Word, Excel, Visual Studio и Visual Studio Code; Google Search использует Gemini не только для генерации ответов, но и для планирования поиска; Яндекс.Алиса управляет смарт‑устройствами, формирует маршруты и выполняет цепочки действий по голосовой команде. Это не «дополнительная функция», а новый уровень взаимодействия человека с программным обеспечением: от «я нажимаю кнопку» к «я описываю цель — система делает остальное».

Настоящее значение агентов заключается не в том, что они «умнее» людей, а в том, что они постоянны, масштабируемы и неутомимы. Один агент может обслуживать миллионы пользователей одновременно, не теряя точности, не забывая инструкций и не отвлекаясь. Но для того чтобы реализовать этот потенциал, требуется понимание не только того, что делает агент, но и как он устроен, как проектируется, как обеспечивается его безопасность и надёжность. Именно этим вопросам и посвящена данная глава.

Что такое ИИ‑агент?​

С технической точки зрения, ИИ‑агент — это автономная программная система, которая сочетает в себе три основных компонента:

  1. Модель рассуждений — обычно большая языковая модель (LLM), выступающая в роли «мозга». Она отвечает за интерпретацию цели, построение плана, выбор тактик и принятие решений на основе контекста.
  2. Инструменты — внешние интерфейсы, через которые агент взаимодействует с миром: API, базы данных, функции кода, поисковые системы, системы управления пользовательским интерфейсом и даже другие агенты. Инструменты — это «руки» агента: без них он может только генерировать текст, но не может выполнять реальные действия.
  3. Уровень оркестрации — управляющий цикл, который организует взаимодействие между моделью и инструментами, управляет состоянием, памятью и логикой выполнения. Это «нервная система», которая решает: когда думать, когда действовать, что наблюдать и как корректировать курс.

Эти три компонента работают в непрерывном цикле, известном как Think–Act–Observe (Думай–Действуй–Наблюдай). Цикл запускается заданием высокого уровня — например, «Организуй командировку для трёх человек на конференцию в Берлине». Агент, получив задачу, сначала сканирует ситуацию: что известно? какие инструменты доступны? какие ограничения действуют? Затем он обдумывает план: «сначала получить список сотрудников, затем проверить их календарь, потом найти рейсы, сравнить цены, забронировать…». После этого он действует: вызывает инструмент «получить состав команды», получает ответ, наблюдает за результатом, добавляет его в контекст и переходит к следующему шагу — и так до завершения миссии.

Важно подчеркнуть: ИИ‑агент не является просто LLM с подключённым API. Это полноценное приложение, в котором LLM — лишь один из модулей, пусть и центральный. Успешная работа агента зависит не столько от параметров модели, сколько от архитектурного решения: как организован контекст, как структурированы инструменты, как реализованы политики безопасности и как обеспечивается наблюдаемость. Именно поэтому простые прототипы агентов создаются за часы, а промышленные системы — за месяцы: необходимо решить не задачу инжиниринга подсказок, а задачу инжиниринга систем.

Таксономия ИИ‑агентов​

Агенты не бывают «просто агентами». Их возможности формируют иерархию уровней зрелости — от изолированной модели до саморазвивающейся команды. В документе Google предложена пятиуровневая классификация, которая позволяет точно оценивать текущие и целевые возможности системы.

Уровень 0: Основная система рассуждений (Reasoning-Only System)​

Этот уровень — предвестник агента, но ещё не агент. Здесь LLM работает в изоляции: она опирается только на знания, заложенные в процессе предобучения, и не имеет доступа ни к внешним данным, ни к инструментам. Такая система может объяснить устройство блокчейна, описать историю Второй мировой войны или предложить структуру алгоритма — но не сможет ответить на вопрос «Какой курс евро сегодня?» или «Кто из моей команды свободен завтра?», потому что эти факты не входят в её обучающий корпус.

Уровень 0 полезен для задач, требующих глубокого объяснения, анализа или генерации идей, но бесполезен для решения практических задач, привязанных к реальному времени или к конкретным данным. Это уровень, на котором работают многие «простые» чат‑боты, не имеющие доступа к базам знаний или API.

Уровень 1: Связанный решатель задач (Connected Problem Solver)​

Переход на этот уровень знаменует появление настоящего агента. Здесь LLM получает доступ к инструментам — и в первую очередь к механизмам поиска информации: RAG (Retrieval-Augmented Generation), векторным базам данных, REST API внешних сервисов (например, Google Search или курс валют). Теперь модель может выполнять действия, выходящие за рамки генерации текста.

Пример: пользователь спрашивает «Кто забил победный гол в вчерашнем матче „Зенита“?». Агент уровня 1 не пытается угадать ответ из общих знаний. Он формулирует задачу (нужны свежие спортивные данные), выбирает инструмент (поиск в интернете по ключевым словам), формирует запрос, получает результат (например, «Артём Дзюба, 87‑я минута») и генерирует корректный ответ на основе реального факта. Важно, что само решение о вызове инструмента принимает модель: уровень оркестрации лишь исполняет выбранный путь.

Уровень 1 — это минимально жизнеспособный агент для большинства бизнес‑сценариев: поддержка клиентов, анализ заявок, генерация отчётов на основе свежих данных. Однако его ограничение — линейность. Такой агент решает одну задачу за шаг, но не планирует многоступенчатые стратегии.

Уровень 2: Стратегическое планирование (Strategic Problem Solver)​

На этом уровне агент начинает думать вперёд. Он не просто реагирует на текущий контекст, а строит многошаговые планы и динамически адаптирует их по ходу выполнения. Ключевая новая способность — контекстная инженерия: агент сам определяет, какой именно контекст ему нужен на каждом этапе, и инициирует его получение.

Рассмотрим задачу: «Найди уютную кофейню на полпути между двумя офисами в Москве». Агент уровня 2 разобьёт её на этапы:

  1. Определить географические координаты обоих адресов.
  2. Вычислить точку середины маршрута.
  3. Сформировать поисковый запрос «кофейни в районе [название района] с рейтингом ≥ 4.0» — то есть он генерирует новый запрос на основе предыдущего результата.
  4. Проанализировать возвращённые заведения: проверить наличие Wi-Fi, ценовой сегмент, отзывы.
  5. Составить краткое сравнение и предложить выбор.

Такой агент умеет делегировать части работы себе самому: он вызывает инструмент «геокодирование», затем — «поиск по местоположению», затем — «анализ текста отзывов». Он не просто вызывает API, а строит цепочку рассуждений, в которой каждый шаг обоснован предыдущим. Более того, он может проактивно помогать: прочитав письмо с подтверждением бронирования отеля, он распознаёт даты и номер брони и самостоятельно добавляет событие в календарь, не дожидаясь команды.

Уровень 2 открывает дверь к персонализированным, долгосрочным взаимодействиям. Агент может «помнить» предпочтения пользователя (через долговременную память), строить долгие сценарии (например, подготовку к экзамену за три месяца) и координировать действия между разными сервисами.

Архитектура основного агента​

Мы уже определили три ключевых элемента агента: модель рассуждений, инструменты и уровень оркестрации. Теперь важно не просто знать их названия, а понимать, как они взаимодействуют, как принимаются решения внутри цикла, и какие архитектурные решения влияют на надёжность и производительность.

Модель: не просто LLM — «мозг» с ограничениями и задачами​

Выбор модели — это не выбор самого «умного» варианта, а выбор наилучшего компромисса между качеством рассуждений, скоростью реакции, стоимостью инференса и способностью корректно использовать инструменты. Например, модель может отлично отвечать на вопросы в бенчмарках, но ошибаться в формате вызова функции (например, пропустить обязательный параметр или выдать JSON с синтаксической ошибкой). Такой агент будет выглядеть умным, но работать ненадёжно.

Поэтому при выборе модели следует учитывать:

  • Точность в задачах вызова инструментов — модель должна уверенно извлекать параметры, соблюдать схемы и следовать протоколам (например, OpenAPI, MCP).
  • Способность к многошаговому планированию — не просто ответить, а объяснить план, разбить задачу на подзадачи и сохранить целостность контекста от шага к шагу.
  • Устойчивость к шуму и неполным данным — реальный мир неидеален: API возвращают ошибки, инструменты могут быть недоступны, пользователь даёт расплывчатые формулировки. Модель должна уметь работать с неопределённостью, а не «ломаться» при первом исключении.

Часто оптимальным решением оказывается гибридная архитектура моделей: тяжёлая модель (например, Gemini 2.5 Pro) используется для первоначального планирования и сложных когнитивных задач, а облегчённая (например, Gemini 2.5 Flash) — для рутинных операций: классификации намерений, резюмирования, извлечения структурированных данных. Такой подход снижает latency и стоимость без потери качества на критических участках.

Важно: модель не должна принимать решения о безопасности. Её выводы должны проходить через детерминированные валидаторы — так называемые ограждения (guardrails), которые проверяют, например, не содержит ли сгенерированный вызов инструмента запрещённых параметров (например, DELETE * FROM users), не превышает ли сумма транзакции лимит и т.д. Это разделение ответственности — фундамент надёжности.

Инструменты: от поиска до изменения мира​

Инструмент — это не просто API. Это чётко определённый контракт, включающий:

  • Назначение — что делает инструмент, на какую задачу он ориентирован (например, «поиск ближайших кофеен» или «отправка уведомления в Slack»).
  • Сигнатура — какие входные параметры он принимает (тип, обязательность, ограничения), и в каком формате возвращает результат.
  • Семантическое описание — как модель должна понимать этот инструмент: когда его вызывать, какие параметры извлекать из контекста, как интерпретировать ошибки.

Типичные категории инструментов:

1. Инструменты поиска и извлечения информации​

Они дают агенту доступ к фактам в реальном времени. Это может быть:

  • Векторный поиск (RAG) — извлечение релевантных фрагментов из базы знаний (например, внутренние регламенты компании, техническая документация).
  • Поиск в вебе — через Google Search API или аналоги: не для «угадывания», а для подтверждения или дополнения знаний.
  • NL2SQL / NL2API — преобразование естественно-языкового запроса в структурированный (например, из «кто из сотрудников был в отпуске в июле?» → SQL-запрос к HR-базе).

Ключевое преимущество: снижение галлюцинаций. Если агент видит, что его внутреннее знание противоречит свежим данным — он должен поверить данным, а не собственной «уверенности».

2. Инструменты исполнения действий​

Они позволяют агенту влиять на состояние внешнего мира:

  • Вызовы REST/gRPC API — обновление CRM, создание задачи в Jira, бронирование ресурсов.
  • Код-выполнение в песочнице — генерация и запуск Python-скрипта для расчётов, преобразования данных, вызова CLI-утилит. Такой инструмент должен быть ограниченным: только доверенные импорты, таймауты, изоляция процессов.
  • Интерфейс с пользователем — не просто отправка текста, а контроль UI: предзаполнение форм, симуляция кликов (например, через Puppeteer или Playwright), адаптация интерфейса под текущую задачу.
3. Инструменты взаимодействия с людьми​

Здесь агент передаёт инициативу человеку:

  • ask_for_confirmation() — «Вы уверены, что хотите отправить это письмо клиенту?»
  • ask_for_missing_info() — «Укажите номер заказа, чтобы я мог найти его»
  • escalate_to_human() — передача задачи оператору при превышении сложности или риска.

Такие инструменты превращают агента не в автономного «робота», а в умного помощника, который знает границы своей компетенции.

Уровень оркестрации​

Если модель — мозг, а инструменты — руки, то оркестратор — центр принятия решений, который гарантирует, что действия будут последовательны, безопасны и наблюдаемы.

Основные функции уровня оркестрации:

  1. Управление состоянием
    Каждый шаг цикла фиксируется: какая задача стояла, какой план был построен, какой инструмент вызван, какие параметры переданы, какой результат получен. Это состояние сохраняется как аффикт (affordance) или сессионный граф, и используется как контекст для следующего шага.

  2. Контроль логики планирования
    Оркестратор определяет:

    • Должен ли агент действовать по фиксированному сценарию (если задача хорошо структурирована: «заполнить форму по шаблону»), или динамически строить план (если цель открыта: «подготовь презентацию по ИИ-агентам»).
    • Когда нужно перепланировать: например, если инструмент вернул ошибку, или если цель изменилась в ходе диалога.

  3. Интеграция политик безопасности
    Перед каждым вызовом инструмента проверяются:

    • Права доступа агента к этому инструменту (через IAM или кастомные политики).
    • Соответствие параметров ограничениям (например, дата не в прошлом, сумма не превышает лимит).
    • Наличие подтверждения от человека для критических действий.

  4. Обеспечение наблюдаемости
    Каждый цикл — это трассировка, совместимая с OpenTelemetry: timestamp, latency, вход/выход модели, имя инструмента, статус выполнения. Эти данные позволяют не просто видеть что сделал агент, но и почему он это сделал.

Важный нюанс: оркестратор может быть как кодом, так и конфигурацией. Например, в Google ADK можно определить workflow как YAML-файл с этапами, инструментами и условиями ветвления — без написания императивного кода. Это ускоряет разработку и делает систему прозрачной для нетехнических экспертов.

Контекст и память​

Контекст — это окно внимания модели. Он не бесконечен, и его содержание должно быть целенаправленным. Неправильная контекстная инженерия — главная причина «потери нити» у агентов.

Краткосрочная память (сессионная)​

Это — активная записная книжка текущего взаимодействия:

  • История пар (действие → наблюдение).
  • Текущая цель и её подцели.
  • Промежуточные выводы (например, «пользователь предпочитает формальный стиль общения»).
  • Ошибки и повторные попытки.

Реализуется через состояние сессии — структуру, которая передаётся на каждый шаг цикла и обновляется оркестратором.

Долгосрочная память​

Это — знания, сохраняемые между сессиями:

  • Предпочтения пользователя (например, «Тимур любит получать ответы с примерами кода на C#»).
  • Результаты выполнения похожих задач («в прошлый раз для анализа логов использовался такой-то скрипт — можно предложить его снова»).
  • Обученные настройки (например, скорректированные после HITL правила фильтрации).

Технически долгосрочная память — это специализированный инструмент RAG, подключённый к векторной БД. Оркестратор решает, когда и какую информацию извлечь: например, перед ответом на вопрос о внутренних процессах — запросить релевантные разделы регламентов.

Ключевой принцип: память должна быть селективной и управляемой. Агент не должен «вспоминать всё подряд» — это приведёт к перегрузке контекста и снижению качества. Вместо этого он должен запрашивать только то, что релевантно цели.

Мультиагентные системы​

Пространственные и когнитивные ограничения единичной языковой модели делают её неэффективной для решения сложных, многоаспектных задач «в одиночку». Попытка создать «суперагента», способного одновременно анализировать рынок, писать технические спецификации, генерировать код и вести переговоры, приводит к размыванию компетенций, росту ошибок и снижению наблюдаемости. На практике более надёжным и масштабируемым решением оказывается разделение труда между специализированными агентами — подход, имитирующий организацию человеческих команд.

Мультиагентная система — это не просто совокупность отдельных агентов. Это структурированная кооперация, в которой каждый агент выполняет чётко определённую роль, а общий результат достигается за счёт их согласованного взаимодействия. Важнейшее архитектурное решение здесь — кто координирует.

Шаблоны проектирования мультиагентных систем​

Google выделяет несколько базовых шаблонов, которые покрывают большинство практических сценариев:

1. Координатор–исполнители (Manager–Specialists)​

Центральная роль отводится координирующему агенту (например, ProjectManagerAgent), который:

  • Принимает высокоуровневую миссию («запустить продукт Solaris»);
  • Разбивает её на подцели (маркетинговый анализ, разработка сайта, юридическая экспертиза);
  • Назначает каждую подцель соответствующему специалисту (MarketResearchAgent, WebDevAgent, LegalAgent);
  • Собирает промежуточные результаты;
  • Принимает решение о дальнейших шагах — повторить, скорректировать, объединить.

Преимущество: гибкость. Координатор может динамически переназначать задачи (например, запросить повторный анализ у MarketResearchAgent, если LegalAgent обнаружил регуляторные риски). Недостаток: координатор становится узким местом — его ошибки в планировании влекут каскадные сбои.

2. Последовательный конвейер (Sequential Pipeline)​

Здесь задача проходит через цепочку агентов строго по порядку, как на производственной линии:

  1. DataExtractorAgent извлекает информацию из неструктурированного документа;
  2. ValidatorAgent проверяет полноту и корректность данных;
  3. ReportGeneratorAgent оформляет результат в требуемом формате;
  4. ReviewerAgent проводит финальную проверку и одобряет отправку.

Этот шаблон эффективен для линейных, хорошо формализованных процессов (например, обработка заявок, генерация отчётов). Он легко поддаётся тестированию и аудиту, но не допускает возвратов и параллельного выполнения.

3. Итеративное уточнение (Iterative Refinement)​

В этой схеме два агента работают в цикле:

  • GeneratorAgent создаёт черновик (контент, код, план);
  • CriticAgent оценивает его по заранее заданным критериям (полнота, безопасность, соответствие стилю);
  • Если оценка ниже порога — GeneratorAgent получает обратную связь и создаёт новую версию.

Цикл продолжается до достижения целевого качества или исчерпания лимита итераций. Такой подход особенно полезен в задачах с высокими требованиями к точности и стилю: юридическая документация, технические спецификации, PR-материалы.

4. Человек в цикле (Human-in-the-Loop, HITL)​

Этот шаблон не заменяет человека, а интегрирует его как компонент системы. Агент умеет распознавать ситуации, требующие вмешательства:

  • Неоднозначность цели («Пользователь запросил „подготовить документ“, но не уточнил тип»);
  • Высокий риск («Предлагаемая сумма транзакции превышает 100 000 ₽»);
  • Нарушение политики («Обнаружена попытка доступа к неавторизованным данным»).

В этих случаях агент приостанавливает выполнение и вызывает инструмент ask_for_confirmation(), ask_for_clarification() или escalate_to_human(). Важно: решение о передаче — не случайное, а результат применения детерминированных правил (например, политики безопасности или бизнес-логики), заложенных на уровне оркестрации.

Безопасность агентов​

Наделение агента полномочиями — неотъемлемая часть его полезности. Но каждое действие, которое агент может выполнить (отправить письмо, прочитать базу данных, вызвать внешний API), создаёт потенциальную угрозу. Поэтому безопасность должна быть встроена на всех уровнях архитектуры, а не добавлена «сверху» как надстройка.

Идентичность агента — новый класс принципалов​

В традиционных системах безопасности есть две категории субъектов:

  • Пользователи (людьми) — аутентифицируются через OAuth/SSO;
  • Служебные учётные записи (машинами) — управляются через IAM.

Агент — это третья категория: автономная сущность, которая действует от имени пользователя, но имеет собственную идентичность, права и жизненный цикл. Каждому агенту должна быть выдана криптографически подтверждённая идентичность (например, на основе стандарта SPIFFE), независимо от создателя и вызвавшего пользователя.

Почему это важно? Потому что:

  • Аудит событий должен фиксировать кто (агент) и от чьего имени (пользователь) выполнил действие;
  • Политики доступа должны применяться к агенту, а не только к его пользователю (например, HRonboardingAgent не должен иметь доступа к финансовой базе, даже если его запустил CFO);
  • При компрометации одного агента ущерб ограничен его полномочиями — это реализация принципа минимальных привилегий.

Политики ограничения доступа​

Политика — это формализованное правило, определяющее, какие действия разрешены в конкретном контексте. Для агентов политики применяются на нескольких уровнях:

УровеньПримеры политик
Доступ к инструментам«Agent X может вызывать send_email(), но только для доменов @company.com»
Параметры вызова«В transfer_money(amount) параметр amount ≤ 10 000, если нет подтверждения от человека»
Доступ к данным«Запрещено извлекать PII (персональные данные) через RAG из нешифрованных источников»
Взаимодействие с другими агентами«Только ProjectManagerAgent может создавать новых агентов»

Политики реализуются двумя способами:

  1. Детерминированные (hard guardrails) — код, выполняющийся вне модели (например, валидатор параметров перед вызовом инструмента). Они предсказуемы и поддаются аудиту.
  2. ИИ‑на основе (soft guardrails) — например, «модель-охранник», которая анализирует план агента перед исполнением и выявляет рискованные шаги (например, попытку генерации SQL с DROP TABLE). Такая система дополняет, но не заменяет детерминированные ограждения.

Практика безопасности в ADK​

Agent Development Kit от Google предоставляет встроенные механизмы для реализации вышеописанных принципов:

  • before_tool_callback — хук, позволяющий проверять параметры инструмента до его вызова (например, убедиться, что recipient_email не содержит доменов конкурентов);
  • Плагины безопасности — повторно используемые модули, например, «Gemini как судья», использующий лёгкую модель (Flash-Lite) для фильтрации вредоносных подсказок в реальном времени;
  • Интеграция с Model Armor — управляемой службой, которая сканирует запросы и ответы на предмет джейлбрейков, утечек PII, вредоносных URL и попыток инъекции.

Ключевой принцип: безопасность — многоуровневая. Ни одна модель, ни один хук не могут быть единственной линией обороны.

Оценка и отладка​

Традиционная разработка оперирует детерминированной логикой: функция при одних и тех же входах всегда возвращает один и тот же результат. Агентная система по своей природе стохастична: даже при фиксированном запросе и неизменных инструментах результат может варьироваться из-за вариаций в поведении языковой модели. Поэтому классические unit-тесты («вывод == ожидаемый») неприменимы. Вместо этого применяется дисциплина Agent Ops — подход к наблюдаемости, основанной на метриках, автоматизированных оценках и трассировке.

Бизнес‑метрики как основа приоритизации​

Перед тем как оценивать «техническое качество», необходимо определить, что означает успех в контексте бизнеса. Это могут быть:

  • Коэффициент завершения миссии — доля задач, полностью завершённых без участия человека;
  • Среднее время выполнения — латентность от постановки цели до финального результата;
  • Удовлетворённость пользователей — например, через NPS или шкалу Likert после взаимодействия;
  • Операционная эффективность — снижение нагрузки на поддержку, рост конверсии, сокращение ошибок при заполнении форм.

Эти метрики измеряются в A/B‑экспериментах: новая версия агента сравнивается с текущей в реальных условиях, а не только в симуляции. Важно: метрика должна быть связана с ценностью — например, не «сколько вызовов к API сделано», а «насколько сократилось время подготовки отчёта».

LM Judge​

Там, где люди — дорого и медленно, вступают в игру модели-судьи. Это специализированные LLM (часто облегчённые, например, Gemini 2.5 Flash-Lite), которым даётся инструкция вида:

«Оцени ответ агента по пятибалльной шкале:

  1. Соответствует ли ответ цели?
  2. Основан ли он на достоверных данных?
  3. Соблюдает ли политики безопасности (не раскрывает PII, не генерирует вредоносный код)?
  4. Следует ли формату (например, JSON с полями X, Y, Z)?
  5. Соответствует ли тон указанной персоне (формальный/дружелюбный/технический)?»

Судья работает на золотом наборе данных — коллекции из десятков или сотен сценариев, с ручно размеченными «идеальными» ответами и критериями оценки. Набор должен охватывать:

  • типовые сценарии (80 % случаев),
  • граничные случаи (например, неоднозначные формулировки),
  • негативные примеры (вредоносные попытки джейлбрейка, prompt injection).

Результаты судьи не принимаются слепо: они калибруются экспертами, и при расхождении >1 балл — пересматривается либо критерий, либо подсказка судье.

Отладка через трассировку OpenTelemetry​

Когда метрика упала, а LM Judge выдал низкую оценку, нужна пошаговая диагностика. Здесь незаменима трассировка в формате OpenTelemetry:

Каждый шаг цикла «Думай–Действуй–Наблюдай» фиксируется как span:

  • think: входной контекст, промпт, модель, latency, внутреннее рассуждение (если включено log_reasoning);
  • act: имя инструмента, параметры вызова (без чувствительных данных — маскировка PII), статус;
  • observe: тип ответа (успех/ошибка), сырые данные (обезличенные), latency API.

Трассировка позволяет ответить на ключевые вопросы:

  • Почему агент выбрал именно этот инструмент?
  • Не пропустил ли он параметр, обязательный по схеме OpenAPI?
  • Повторяется ли одна и та же ошибка у разных пользователей — значит, проблема в инструкции, а не в случае?
  • Где именно цепочка разорвалась: на этапе планирования, вызова или интерпретации?

В Google Cloud такие трассировки визуализируются в Cloud Trace, а в Prometheus/Grafana — агрегируются в метрики вроде «доля вызовов send_email() с пустым recipient».

Цикл улучшения через обратную связь от людей​

Автоматические оценки — мощный инструмент, но они не заменяют человеческое суждение в сложных доменах. Особенно важно собирать:

  • Явную обратную связь (кнопки «👍/👎», формы жалоб);
  • Неявную — например, если пользователь повторно переформулирует запрос, вероятно, первый ответ был неполным;
  • Случаи эскалации в HITL — когда агент сам запросил помощь.

Такие события агрегируются и при достижении порога (например, 5 одинаковых жалоб за день) инициируется процесс:

  1. Воспроизведение сценария в sandbox;
  2. Анализ трассировки;
  3. Формулировка корректирующего действия (уточнение системного промпта, добавление примера, ввод нового guardrail);
  4. Включение сценария в золотой набор для будущих оценок.

Таким образом, каждый сбой становится обучающим примером, а не просто инцидентом.

Как агенты учатся и развиваются​

Развернув агента, нельзя «забыть» о нём: внешняя среда меняется — появляются новые API, обновляются регламенты, меняются предпочтения пользователей. Если агент не адаптируется, его полезность экспоненциально падает («старение агента»). Современные системы решают это за счёт встроенных механизмов самообучения.

Контекстная инженерия как основной механизм адаптации​

Наиболее практичный и доступный способ — динамическое обновление контекста:

  • Уточнение системного промпта на основе частых ошибок (например, если агент часто путает «забронировать» и «отменить», в инструкцию добавляется явное правило);
  • Обогащение few-shot примеров — при выявлении нового паттерна взаимодействия к промпту добавляется пример корректного поведения;
  • Адаптивный RAG — если в базе знаний появляется новый документ (например, обновлённый HR-регламент), агент может быть настроен на предзагрузку этой информации при старте сессии для определённых категорий пользователей.

Такой подход не требует переобучения модели, но требует инфраструктуры для:

  • мониторинга изменений в источниках данных;
  • валидации новых примеров (чтобы не внести ошибку в инструкцию);
  • A/B-тестирования обновлённого контекста.

Динамическое создание и модификация инструментов​

На уровне 4 таксономии агент приобретает способность расширять свои возможности:

  • При обнаружении пробела («мне нужно анализировать тональность в Twitter, но такого инструмента нет») агент может вызвать ToolCreator — высокоуровневый инструмент, который генерирует и тестирует новый скрипт (например, на Python с использованием библиотеки tweepy + textblob);
  • Если API изменилось (например, v1/users → v2/profiles), агент может предложить обновление схемы вызова, а после одобрения — заменить сигнатуру инструмента;
  • В многоагентной системе агент-наблюдатель может выявить, что один из исполнителей часто ошибается в расчётах, и предложить подключить к нему «критика» как промежуточную проверку.

Важно: такие действия происходят не в продакшене, а в sandbox с последующей валидацией и ручным подтверждением — особенно на ранних этапах внедрения.

Многоагентное обучение через критику и обобщение​

Рассмотрим пример из финансовой отчётности:

  1. Генератор создаёт черновой отчёт на основе данных из ERP.
  2. Критик проверяет его на соответствие регуляторным требованиям (например, МСФО 16), используя правила из внутренней базы знаний.
  3. При неоднозначности — эскалация человеку-эксперту.
  4. Обучающий агент анализирует цепочку: какой фрагмент вызвал неоднозначность? Какой комментарий дал эксперт? Из этого он формирует обобщённый афифакт:

    «Если в отчёте упоминается „переоценка ОС“, но не указан метод амортизации — всегда требовать уточнения».

Этот афифакт сохраняется в долгосрочную память и становится частью контекста для следующих сессий критика. Таким образом, система накапливает доменные знания, даже если они изначально не были в обучающих данных модели.

Agent Gym​

Контекстная инженерия и многоагентное обучение происходят в реальном времени — «в линии». Но для сложных задач (например, научные гипотезы, оптимизация chips) требуется автономная среда обучения, не влияющая на пользователей. Такую роль играет Agent Gym — виртуальная «тренажёрная площадка» для агентов.

Ключевые свойства Agent Gym:

  • Вне пути выполнения — запускается как отдельный pipeline (например, nightly job), не затрагивая продакшен;
  • Полная изоляция — можно подключать любые модели (включая экспериментальные), инструменты, симуляторы внешних систем;
  • Генерация синтетических данных — создание стресс-кейсов:
    • «красные команды» — атаки prompt injection, попытки обхода политики;
    • «чёрные лебеди» — редкие, но критичные сценарии (например, одновременный отказ двух API);
  • Эволюционные стратегии — например, генерация 100 вариантов плана, оценка их через судью, отбор топ-10, мутация и повтор.

Agent Gym позволяет агенту «пережить тысячи жизней за ночь», не подвергая риску реальных пользователей. Результаты — не только новые инструменты, но и оптимизированные шаблоны проектирования: например, выясняется, что для задачи X лучше использовать «итеративное уточнение» с 3 итерациями, а не «координатора».

Примеры передовых систем: Co-Scientist и AlphaEvolve​

Google Co-Scientist​

Co-Scientist — это мультиагентная система уровня 3+, созданная для ускорения научных открытий. Её архитектура включает:

  • Supervisor Agent — анализирует исследовательскую цель (например, «найти связь между геном X и болезнью Y»), строит план, распределяет ресурсы;
  • Literature Agent — систематически обходит научные базы (PubMed, arXiv), извлекает релевантные статьи, строит карту знаний;
  • Hypothesis Generator — на основе найденных связей формулирует новые гипотезы;
  • Validation Agent — проверяет их на внутреннюю непротиворечивость и соответствие известным фактам;
  • Experiment Designer — предлагает in silico эксперименты для проверки.

Система работает циклами: каждый цикл — поколение гипотез, метацик — оптимизация метода генерации. За 48 часов Co-Scientist может проработать пространство, которое команда из 5 учёных исследует месяцами.

AlphaEvolve​

AlphaEvolve специализируется на задачах, где проверка решения проще, чем его поиск — например, оптимизация кода, открытие математических тождеств.

Цикл работы:

  1. Агент генерирует кандидат-решение (например, алгоритм умножения матриц);
  2. Оценщик запускает его на benchmark-наборе (время, память, корректность);
  3. Лучшие кандидаты отбираются как «родители»;
  4. С помощью кроссовера и мутации (управляемых LLM) создаются новые варианты;
  5. Цикл повторяется до достижения порога или исчерпания бюджета.

Результаты:

  • Новые алгоритмы умножения матриц, быстрее существующих на 5–10 %;
  • Оптимизация layout микросхем, сократившая энергопотребление на 12 %;
  • Решения открытых задач в комбинаторике.

Ключевое преимущество — прозрачность: решения выдаются в виде читаемого кода, который можно проанализировать, модифицировать и внедрить.